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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document constitutes the stage 2 specification of different synchronisation mechanisms in UTRAN and on 
Uu. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[ 1 ] 3GPP TS 25 .40 1 : "UTRAN Overall Description" . 

[2] 3GPP TS 25.423: "UTRAN lur Interface RNSAP Signalling". 

[3] 3GPP TS 25.433: "UTRAN lub Interface NBAP Signalling". 

[4] 3GPP TS 25.435: "UTRAN lub Interface User Plane Protocols for COMMON TRANSPORT 

CHANNEL Data Streams". 

[5] 3GPP TS 25.427: "lub/Iur Interface User Plane Protocol for DCH Data Streams". 

[6] TIA/EIA 422 B: "Electrical characteristics of balanced voltage digital interface circuits". 

[7] 3GPP TS 25 .4 1 1 : " UTRAN lu Interface Layer 1 " . 

[8] 3GPP TS 25.421: "UTRAN lur Interface Layer 1". 

[9] 3GPP TS 25 .43 1 : " UTRAN lub Interface Layer 1 " . 

[10] 3GPP TS 25.104: "UTRA (BS) FDD; Radio transmission and Reception". 

[11] 3GPP TS 25 .2 11 : "Physical channels and mapping of transport channels onto physical channels 

(FDD)". 

[12] 3GPP TS 25.223: "Spreading and modulation (TDD)". 

[13] 3GPP TS 25.215: "Physical layer - Measurements (FDD)". 

[14] 3GPP TS 25.225: "Physical layer - Measurements (TDD)". 

[15] 3GPP TS 25.123: "Requirements for Support of Radio Resource Management (TDD)". 

[ 1 6] 3GPP TS 25 .224: "Physical Layer Procedures (TDD)" . 

[17] 3GPP TS 25.105: "UTRA (BS) TDD, Radio transmission and Reception". 

[18] ITU-T Recommendation G.811 (09/1997): "Timing Characteristics of Primary Reference Clocks". 

[19] ITU-T Recommendation G.812 (06/1998): "Timing Requirements of Slave Clocks suitable for use 

as Node Clocks in Synchronization Network". 

[20] ITU-T Recommendation G.813 (08/1996): "Timing Characteristics of SDH equipment slave 

clocks (SEC)". 
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[21] ETSI EN 300 462-4-1(03/1998): "Transmission and Multiplexing (TM); Generic requirements for 

synchronization networks; Part 4-1: Timing characteristics of slave clocks suitable for 
synchronization supply to Synchronous Digital Hierarchy (SDH) and Plesiochronous Digital 
Hierarchy (PDH) equipment". 

[22] ETSI EN 300 462-5-1 (09/1996):"Transmission and Multiplexing (TM); Generic requirements for 

synchronization networks; Part 5-1: Timing characteristics of slave clocks suitable for operation in 
Synchronous Digital Hierarchy (SDH) equipment". 

[23] ETSI EN 300 462-7-1 (04/2001): "Transmission and Multiplexing (TM); Generic requirements for 

synchronization networks; Part 7-1: Timing characteristics of slave clocks suitable for 
synchronisation supply to equipment in local node applications". 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

Network Synchronisation: generic concept that depicts the way of distributing a common frequency to all elements in 
a network 

Reference Timing Signal: timing signal of specified performance that can be used as a timing source for a slave clock 

Holdover mode: operating condition of a clock which has lost its controlling reference input and is using stored data, 
acquired while in locked operation (that is while controlled by an external input reference), to control its output. The 
stored data are used to control phase and frequency variations, allowing the locked condition to be reproduced within 
specifications. 

3.2 Symbols 

No special symbols are defined in this document. 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ACK (time alignment) acknowledgement 

BEN Node B Frame Number (counter) 

CFN Connection Frame Number (counter) 

CH Channel 

CN Core Network 

CRNC Controlling RNC 

DL Down Link 

DCH Dedicated Channel 

DOFFfdd FDD Default DPCH Offset value 

DOFFtdd TDD Default DPCH Offset value 

DPCH Dedicated Physical Channel 

DPCCH Dedicated Physical Control Channel 

DRNC Drift RNC 

DSCH Downlink Shared Channel 

FACH Forward Access Channel 

FDD Frequency Division Duplex 

GPS Global Positioning System 

HO Handover 

LTOA Latest Time of Arrival 

LI Layer 1 

L2 Layer 2 

MAC Medium Access Control 

NACK (time alignment) negative acknowledgement 
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PCCPCH Primary Common Control Physical Channel 

PCH Paging Channel 

PDU Packet Data Unit 

PUSCH Physical Uplink Shared Channel 

RAB Radio Access Bearer 

RACH Random Access Channel 

RAN Radio Access Network 

RFN RNC Frame Number (counter) 

RL Radio Link 

RNC Radio Network Controller 

RNS Radio Network Subsystem 

RRC Radio Resource Control 

SFN Cell System Frame Number (counter) 

SRNC Serving RNC 

SRNS Serving RNS 

TBS Transport Block Set 

TDD Time Division Duplex 

TOA Time Of Arrival 

TO AWE Time Of Arrival Window Endpoint 

TOAWS Time Of Arrival Window Startpoint 

TTI Time Transmission Interval 

UE User Equipment 

UL Up Link 

USCH UpUnk Shared CHannel 

UTRAN UMTS Terrestrial Radio Access Network 



Synchronisation Issues 



4.1 



General 



This clause identifies the different UTRAN synchronisation issues, i.e.: 

Network Synchronisation; 

Node Synchronization; 

Transport Channel Synchronisation; 

Radio Interface Synchronisation; 

Time Alignment Handling. 

The Nodes involved by the above mentioned synchronisation issues (with the exception of Network and Node 
Synchronisation) are shown by the Synchronisation Issues Model of Figure 1. 
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Figure 1 : Synchronisation Issues Model 

The UTRAN solutions for most of the identified items are described in clauses 6-10. Additional information on 
UTRAN synchronisation issues and the detailed specification of UTRAN solutions can be found in the following 
Technical Specifications: 

Summary of UTRAN Synchronisation Issues: 

TS 25.401 "UTRAN Overall Description", clause 9. 

Network Synchronisation: 

TS 25.411 "UTRAN lu Interface Layer 1", subclause 4.2; 

TS 25.104 "UTRA (BS) FDD; Radio transmission and reception", subclause 6.3; 

TS 25.105 "UTRA (BS) TDD, Radio transmission and reception", subclause 6.3. 

- RNC-Node B Node Synchronisation: 

TS 25.427 "lub/Iur Interface User Plane Protocol for DCH Data Streams", subclause 5.5; 

TS 25.435 "UTRAN lub Interface User Plane Protocols for COMMON TRANSPORT CHANNEL Data 
Streams", subclause 5.2. 

Transport Channel Synchronisation: 

TS 25.427 "lub/Iur Interface User Plane Protocol for DCH Data Streams", subclauses 5.2 - 5.3; 

TS 25.435 "UTRAN lub Interface User Plane Protocols for COMMON TRANSPORT CHANNEL Data 

Streams", subclauses 5.3 - 5.4. 

Time Alignment Handling: 

TS 25.415 "UTRAN lu Interface User Plane Protocols", subclauses 6.5.4. 



4.2 Network Synchronisation 



Network Synchronisation relates to the distribution of synchronisation references to the UTRAN Nodes and the stability 
of the clocks in the UTRAN (and performance requirements on UTRAN internal interfaces). 

The distribution of an accurate frequency reference to the network elements in the UTRAN is related to several aspects. 
One main issue is the possibility to provide a synchronisation reference with a frequency accuracy better than 0.05 ppm 
at the Node B in order to properly generate signals on the radio interface (see references [10] and [17]). 
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A general recommendation is to supply a traceable synchronisation reference according to reference [18]. 

The clock to be implemented in UTRAN Nodes shall be chosen with characteristics that depends on the LI adopted (see 
reference [8] and [9]) and on the Network Synchronisation strategy adopted. Already standardized clocks may be used 
(see references [19], [20], [21], [22] and [23]). 

For example in order to support STM-N interfaces at the RNC, the ITU-T Recommendation G.813 (see reference [20]) 
may be sufficient. The implementation in the UTRAN of a better performing clock (in terms of holdover) may be 
recommended for distribution of a 0.05 ppm during failures in the synchronisation network (EN 300 462-7-1, see 
reference [23], EN 300 462-4-1, see reference [21], or ITU-T Recommendation G.812 type 1, type 2 or type 3, see 
reference [19]). 



4.3 Node Synchronisation 



Node Synchronisation relates to the estimation and compensation of timing differences among UTRAN nodes. FDD 
and TDD modes have different requirements on the accuracy of the timing difference estimation and on the necessity to 
compensate for these differences. 

Two types of Node Synchronisation can be identified, "RNC-Node B" and "Inter Node B" Node Synchronisation. Their 
usage differs and the requirements differ between the FDD and TDD modes. 

"RNC-Node B" Node Synchronisation allows to get knowledge of the timing differences between RNC and its Node 
Bs. 

"Inter Node B" Node Synchronisation may be used in the TDD mode to compensate the timing differences among Node 
Bs in order to achieve a common timing reference. The purpose of having a common timing reference is to allow 
Intercell Synchronisation, which is used, within neighbouring cells to minimise cross-interference. 

Positioning / Localisation functions may also set requirements on Node Synchronisation. 

4.4 Transport Channel Synchronisation 

The Transport Channel Synchronisation mechanism defines synchronisation of the frame transport between RNC and 
Node B, considering radio interface timing. 

DL TBS transmission is adjusted to fit receiver by adjusting the DL TBS timing in upper node. UL TBS transmission is 
adjusted by moving the UL reception window timing internally in upper node. 



4.5 Radio Interface Synchronisation 



The Radio Interface Synchronisation relates to the timing of the radio frame transmission (either in downlink [FDD] or 
in both directions [TDD]). FDD and TDD have different mechanisms to determine the exact timing of the radio frame 
transmission and also different requirements on the accuracy of this timing. 

In FDD Radio Interface Synchronisation is necessary to assure that the UE receives radio frames synchronously from 
different cells, in order to minimise UE buffers. 

In TDD Radio Interface Synchronisation refers to the following two aspects: 

Intercell Synchronisation that is used to synchronise radio frames within neighbouring cells in order to minimise 
cells cross-interference, to allow frame wise hopping mechanisms among cells (e.g. Cell Parameter Cycling 
according to reference [12]) and to make procedures involving more cells (e.g. handover) easier and more 
efficient; 

Timing advance that is used between UE and UTRAN in order to minimise UE-cell interference. In the 1.28 
Mcps TDD option, timing advance is provided by uplink synchronisation. 
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4.6 Time Alignment Handling 



The Time Alignment Handling procedure over lu relates to the control of DL transmission timing in the CN nodes in 
order to minimise the buffer delay in SRNC. This procedure is controlled by SRNC. 



4.7 Uplink Synchronisation 



In 1.28Mpcs TDD Uplink Synchronisation is performed at Layer 1 for PRACH and uplink DPCH. This procedure 
includes the establishment of UL synchronisation and maintenance of the UL synchronisation. 



5 Synchronisation Counters and Parameters 

This clause defines counters and parameters used in the different UTRAN synchronisation procedures. 

The parameters used only by FDD has been indicated with the notation [FDD - parameter]. 

BFN Node B Frame Number counter. This is the Node B common frame number counter. 

[FDD -BFN is optionally frequency-locked to a Network sync reference]. 
Range: to 4095 frames. 

RFN RNC Frame Number counter. This is the RNC node common frame number counter. RFN 

is optionally frequency-locked to a Network sync reference. 
Range: to 4095 frames. 

SFN Cell System Frame Number counter. SFN is sent on BCH. SFN is used for paging groups 

and system information scheduling etc. 
In FDD SFN = BFN adjusted with T_cell. 

In TDD, if Inter Node B synchronisation port is used, SFN is locked to the BFN (i.e. SFN 
mod 256 = BFN mod 256). 
Range: to 4095 frames. 

CFN Connection Frame Number (counter). CFN is the frame counter used for the L2/transport 

channel synchronisation between UE and UTRAN. A CFN value is associated to each TBS 
and it is passed together with it through the MAC-Ll SAP. CFN provides a common frame 
reference (at L2) to be used e.g. for synchronised transport channel reconfiguration 
(see [2] and [3]). 

The duration of the CFN cycle is longer than the maximum allowed transport delay 
between MAC and LI (in UTRAN side, between SRNC and Node B, because the LI 
functions that handle the transport channel synchronisation are in the Node B). 
Range: to 255 frames. When used for PCH the range is to 4095 frames. 

Frame Offset Frame Offset is a radio link specific LI parameter used to map the CFN, used in the 

transport channel, into the SFN that defines the specific radio frame for the transmission on 
the air interface. 

At the L1/L2 interaction, the mapping is performed as: 

- SFN mod 256 = (CFN + Frame Offset) mod 256 (fi-om L2 to LI) (5.1); 

- CFN = (SFN - Frame Offset) mod 256 (from LI to L2) (5.2). 

The resolution of all three parameters is 1 frame. Frame Offset and CFN have the same 
range (0...255) and only the 8 least significant bits of the SFN are used. The operations 
above are modulo 256. 

In the UTRAN, the Frame Offset parameter is calculated by the SRNC and provided to the 
node B. 
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OFF The parameter OFF is calculated by the UE and reported to the UTRAN only when the 

UTRAN has requested the UE to send this parameter. In the neighbouring cell list, the 
UTRAN indicates for each cell if the Frame Offset is already known by the UTRAN or 
shall be measured and reported by the UE. 

OFF has a resolution of 1 frame and a range of to 255. 

Five different cases are discerned related to the determination of the OFF value by the UE: 

1. The UE changes from common channel state to dedicated channel state: 1 RL. 
In this case OFF is zero. 

2. [FDD -The UE changes from common channel state to dedicated channel state: several 
RL's. 

OFF is in this case defined as being the difference between SEN of the candidate cells 
and the SEN of the camping cell. Again the UE sets OFF to zero for the cell to which 
the UE sends an UL RRC message (cell #1). For cells #2 to n, the UE sets OFF to the 
difference between the SFN of cell#2,n and the SEN of cell#l . 

This could be seen as if a virtual dedicated physical channel (DPCH) already is aligned 
with cell #1]. 

3. The UE adds another RL or moves to another cell in dedicated channel state. 

OFF is in this case defined as being the time difference between the CEN and the SFN 
of the cell in which the RL is to be added. In case this difference cannot be measured, a 
value as in [FDD - 13] [TDD - 14] shall be reported instead. 

4. The UE is coming from another RAN and goes to dedicated channel state: 1 RL 
This case is identical to case 1). 

5. [FDD - The UE is coming from another RAN or another frequency in the same RAN 
and goes to dedicated channel state: several RL's. 

This case is identical to case 2), with one exception: OFF will not be zero for the cell to 
which the UE sends an UL RRC message (the measurement information will be 
received via the CN in this case) but for a reference cell selected by the UE. All other 
reported OFF values will be relative to the SFN of this selected reference cell]. 

[FDD - DOFFfdd] The DOEEpDo (FDD Default DPCH Offset value) is used to define Frame Offset and Chip 

Offset at first RL setup. The resolution should be good enough to spread out load over lub 
and load in Node B (based on certain load distributing algorithms). In addition it is used to 
spread out the location of Pilot Symbol in order to reduce the peak DL power since Pilot 
symbol is always transmitting at the fixed location within a slot (the largest number of chips 
for one symbol is 512 chips). 

The SRNC sends a DOEEpno parameter to the UE when the new RL will make the UE 
change its state (from Cell_FACH state or other when coming from another RAN) to 
CelLDCH state. 

Resolution: 512 chips; Range:0 to 599 (< 80 ms). 

[TDD - DOFFtdd] The DOFFtdd (TDD Default DPCH Offset value) is used to define Frame Offset at first RL 
setup, in order to spread out load over /lur and load in Node B (based on certain load 
distributing algorithms). 

The SRNC sends a DOFFtdd parameter to the UE when the new RL will make the UE 
change its state (from Cell_FACH state or other when coming from another RAN) to the 
CelLDCH state. 

Resolution: 1 frame; Range: to 7 frames. 
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[FDD - Chip Offset] The Chip Offset is used as offset for the DL DPCH relative to the PCCPCH timing. The 
Chip Offset parameter has a resolution of 1 chip and a range of to 38399 (< 10 ms). 

The Chip Offset parameter is calculated by the SRNC and provided to the Node B. 

Frame Offset + Chip Offset (sent via NBA?) are in Node B rounded together to closest 
256 chip boundary. The 256 chip boundary is used regardless of the used spreading factor, 
also when the spreading factor is 512. The rounded value (which is calculated in Node B) 
controls the DL DPCH air-interface timing. 

The "Frame Offset + Chip Offset" 256 chip boundary rounding rules for Node B to 
consider for each DL DPCH are: 

1. IF (Frame Offset x 38 400 + Chip Offset) modulo 256 [chips] = { L.127} THEN round 
(Frame Offset x 38 400 + Chip Offset) modulo 256 frames down to closest 256 chip 
boundary. 

2. IF (Frame Offset x 38 400 + Chip Offset) modulo 256 [chips] = { 128. .255 } THEN 
round (Frame Offset x 38 400 + Chip Offset) modulo 256 frames up to closest 256 chip 
boundary. 

3. IF (Frame Offset x 38 400 + Chip Offset) modulo 256 [chips] = THEN "Frame Offset 
X 38 400 + Chip Offset" is already on a 256 chip boundary. 

[FDD - DPCH Frame Offset] 

The DPCH Frame Offset is used as offset for the DL DPCH relative to the PCCPCH timing 
at both the Node B and the UE. The DPCH Frame Offset parameter has a resolution of 256 
chips and a range of to 38144 chips (< 10 ms). 

The DPCH Frame Offset is equivalent to Chip Offset rounded to the closest 256 chip 
boundary. It is calculated by the SRNC and sent to the UE by the SRNC for each radio link 
in the active set. 

The DPCH Frame Offset controls the DL DPCH air-interface timing. It enables the DL 
DPCHs for radio links in the Active Set to be received at the UE at approximately the same 
time, which can then be soft combined during soft handover. 

[FDD -Tm] The reported Tm parameter has a resolution of 1 chip and a range of to 38399. The Tm 

shall always be sent by the UE. 

Five different cases are discerned related to the determination of the Tm value by the UE: 

1. The UE changes from common channel state to dedicated channel state: 1 RL. 
In this case the Tm will be zero. 

2. The UE changes from common channel state to dedicated channel state: several 
RL's. 

Tm is in this case defined as being the time difference between the received 
PCCPCH path of the source cell and the received PCCPCH paths of the other target 
cells. Again the UE sets Tm to zero for the cell to which the UE sends an UL RRC 
message (cell #1). For cells #2 to n, the UE sets Tm to the time difference of the 
PCCPCH reception timing of cell#2,n from the PCCPCH reception timing of cell#l . 

3. The UE adds another RL in dedicated channel state (macro-diversity). 

Tm is in this case defined as being the time difference between "Tuetx - To" and the 
earliest received PCCPCH path of the target cell. Tuetx is the time when the UE 
transmits an uplink DPCCH frame, hence "Tuetx - To" is the nominal arrival time 
for the first path of a received DPCH. 

4. The UE is coming from another RAN and goes to dedicated channel state: 1 RL. 
This case is identical to case 1. 

5. The UE is coming from another RAN or another frequency in the same RAN and 
goes to dedicated channel state: several RL's. 
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[FDD - T_cell] 



This case is identical to case 2, with one exception: Tm will not be zero for the cell 
to which the UE sends an UL RRC message (the measurement information will be 
received via the CN in this case) but for a reference cell selected by the UE. All 
other reported Tm values will be relative to the timing of the PCCPCH in this cell. 

T_cell represents the Timing delay used for defining the start of SCH, CPICH and the DL 
Scrambling Code(s) in a cell relative BEN. The main purpose is to avoid having 
overlapping SCHs in different cells belonging to the same Node B. A SCH burst is 
256 chips long. SEN in a cell is delayed T_cell relative BEN. 



Tl 



T2 



T3 



T4 



TOAWS 



TOAWE 



LTOA 



TOA 



Resolution: 256 chips. Range: .. 9 x 256 chips. 

RNC specific frame number (REN) that indicates the time when RNC sends the DL Node 
Synchronisation control frame through the SAP to the transport layer. 

Resolution: 0.125 ms; Range: 0-40959.875 ms. 

Node B specific frame number (BEN) that indicates the time when Node B receives the 
correspondent DL Node Synchronisation control frame through the SAP from the transport 
layer. 

Resolution: 0.125 ms; Range: 0-40959.875 ms. 

Node B specific frame number (BEN) that indicates the time when Node B sends the UL 
Node Synchronisation control frame through the SAP to the transport layer. 

Resolution: 0.125 ms; Range: 0-40959.875 ms. 

RNC specific frame number (REN) that indicates the time when RNC receives the UL 
Node Synchronisation control frame. Used in RNC locally. Not standardised over Tub. 

TOAWS (Time of Arrival Window Startpoint) is the window startpoint. DL data frames are 
expected to be received after this window startpoint. TOAWS is defined with a positive 
value relative Time of Arrival Window Endpoint (TOAWE) (see Eigure 10). A data frame 
arriving before TOAWS gives a Timing Adjustment Control frame response. 
The resolution is 1 ms, the range is: {0 .. CEN length/2 -1 ms}. 

TOAWE (Time of Arrival Window Endpoint) is the window endpoint. DL data frames are 
expected to be received before this window endpoint (see Eigure 10). TOAWE is defined 
with a positive value relative Latest Time of Arrival (LTOA). A data frame arriving after 
TOAWE gives a Timing Adjustment Control frame response. 
The resolution is 1 ms, the range is: {0 .. CEN length -1 ms}. 

LTOA (Latest Time of Arrival) is the latest time instant a Node B can receive a data frame 

and still be able to process it. Data frames received after LTOA can not be processed 

(discarded). LTOA is defined internally in Node B to be a processing time before the data 

frame is sent in air-interface. The processing time (Tproc) could be vendor and service 

dependent. 

LTOA is the reference for TOAWE (see Eigure 14). 

TOA (Time of Arrival) is the time difference between the TOAWE and when a data frame 

is received. A positive TOA means that data frames are received before TOAWE, a 

negative TOA means that data frames are received after TOAWE. Data frames that are 

received after TOAWE but before LTOA are processed by Node B. 

TOA has a resolution of 125 )is. TOA is positive when data frames are received before 

TOAWE (see Eigure 12). 

The range is: {0 .. H-CEN length/2 -125 )is}. 

TOA is negative when data frames are received after TOAWE. 

The range is: {-125 [l& .. -CEN length/2}. 
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Node Synchronisation 



6.1 



General 



By Node Synchronisation it's generally meant the achievement of a common timing reference among different nodes. In 
UTRAN although a common timing reference among all the nodes could be useful, it is not required. In fact different 
nodes' counters (RFN and BFN), even if frequency-locked to the same network synchronisation reference, may be not 
phased aligned (see Figure 2). 




Figure 2: Timing of UTRAN counters 

However in order to minimise the transmission delay and the buffering time for the DL transmission on the air 
interface, it can be useful to estimate the timing differences between RNC and Node Bs, without the need to compensate 
for the phase differences between RNC's and Node B's counters. 

On the other hand the achievement of a common timing reference among Node B's may be used in TDD to support Cell 
Synchronisation. 

For these reasons in UTRAN node synchronisation refers to the following two aspects: 

- RNC-Node B Node Synchronisation; 

- Inter Node B Node Synchronisation. 

6.1 .1 RNC-Node B Node Synchronisation 

The Node Synchronisation between RNC and Node B can be used to find out the timing reference differences between 
the UTRAN nodes (RFN in RNC and BFN in Node B). The use is mainly for determining good DL and UL offset 
values for transport channel synchronisation between RNC and their Node B's. Knowledge of timing relationships 
between these nodes is based on a measurement procedure called RNC-Node B Node Synchronisation Procedure. The 
procedure is defined in the user plane protocols for lub (DCH, DSCH, and FACH/PCH) and lur (DCH). 

When the procedure is used from SRNC over the DCH user plane, it allows finding out the actual round-trip-delay a 
certain service has (as the Node Synchronisation Control Frames are transferred the same way as the DCH frames). 

The procedure may also be carried out over a high priority transport bearer (beneficial when used between CRNC and 
Node Bs for the RNC-Node B Synchronisation purpose). Measurements of node offsets can be made at start or restart 
as well as during normal operation to supervise the stability of the nodes. 

If an accurate Reference Timing Signal is used, the frequency deviation between nodes will be low, but could occur. If 
no accurate Reference Timing Signal is available, the local node reference oscillator must be relied upon. Then the 
RNC-Node B Node Synchronisation procedure can be used as a background process to find out the frequency deviation 
between nodes. 

In the RNC-Node B Node Synchronisation procedure, the RNC sends a DL Node Synchronisation control frame to 
Node B containing the parameter TL Upon reception of a DL Synchronisation control frame, the Node B shall respond 
with UL Synchronisation Control Frame, indicating T2 and T3, as well as Tl which was indicated in the initiating DL 
Node Synchronisation control frame (see Figure 3). 
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These two paths (T2-T1 + T4-T3) give together the Round Trip Delay (RTD) 

A 



vo path 



^ 



SRNC 



NodeB 




T2; 




RFN 



4505.000] 



153 



BFN 



Figure 3: RNC-Node B Node Synchronisation 

In case of macrodiversity with recombining in the DRNC, the DL Node Synchronisation control frame is dupHcated in 
the DRNC on the different links, while the UL Node Synchronisation control frames received from all the Node B's are 
forwarded transparently to the SRNC (see Figure 4). 
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Figure 4: [FDD - RNC-Node B Node Synchronisation during soft handover 
with selection/recombining in the DRNC] 

6.1 .2 Inter Node B Node Synchronisation 

In the FDD mode Inter Node B Node Synchronisation could be reached via the RNC-Node B Node Synchronisation in 
order to determine inter Node B timing reference relations. 

This could be used to determine Inter-cell relationships (considering T_cell) which can be used in the neighbour cell 
lists in order to speed up and simplify cell search done by UE at handover. 

In TDD Inter Node B Node Synchronisation is used to achieve a common timing reference among Node B's (see 
Figure 5), that allows to support Intercell Synchronisation. 
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Figure 5: Synchronisation of BFNs through TDD Inter Node B Synchronisation 

In TDD Inter Node B Node Synchronisation may be achieved via a standardised synchronisation port 
(see subclause 6.1.2.1) that allows to synchronise the Node B to an external reference. 

Another option to achieve the Inter Node B Node Synchronisation in a TDD system is the synchronisation of cells or 
Node Bs via the air interface (see subclause 6.1.2.2). 



6.1.2.1 



TDD Node B Synchronisation Ports 



This subclause defines the Node B input and an output synchronisation ports that can be used for Inter Node B Node 
Synchronisation. These synchronisation ports are optional. 

The input synchronisation port (SYNC IN) allows the Node B to be synchronised to an external reference (e.g. GPS), 
while the output synchronisation port (SYNC OUT) allows the Node B to synchronise directly another Node B 
(see Figure 6). 



External 

Sync. 

Source 



Node B 



Adaptor 




Figure 6: Usage of Synchronisation Ports 

This allows connecting Node B's in a daisy chain configuration, so that a single external reference is enough and all 
remaining Node B's can be synchronised (e.g. in case of indoor operation). 

The Node B starts the synchronisation to the external reference when a valid input synchronisation signal is detected at 
the input synchronisation port. 

If a valid synchronisation signal is detected, the Node B regenerates that signal at its output synchronisation port. 

The electrical characteristics of the synchronisation ports shall conform to RS422 [6] (output synchronisation port: 
subclause 4.1; input synchronisation port: subclause 4.2). 
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The synchronisation signal (illustrated in Figure 7a) is a 100 Hz signal having positive pulses of width between 5 )is and 
1 ms, with the following exceptions: 

when (SFN mod 256 = 0) and not (SEN mod 4096 = 0), the pulse shall have a width between 2 ms and 3 ms. 

This signal establishes the 10 ms frame interval, the 2.56 s multiframe interval, and the 4096 frames SFN period. The 
start of all frames in the cell of the node B is defined by the falling edge of the pulse. The required accuracy for the 
phase difference between the start of the 10ms frame interval is defined in [15]. The time delay from the falling edge of 
the signal at the SYNC IN port to the start of the transmitted radio frame shall not exceed 500ns. 

The start of the 256 frame period is defined by the falling edge of the pulse corresponding to the frames where SFN 
mod 256 =0 (i.e. of width between 2 ms and 3 ms, or between 4ms and 5 ms, respectively). 

The start of the 4096 frame period is defined by the falling edge of the pulse corresponding to the frames where SFN 
mod 4096 = (i.e. of width between 4 ms and 5 ms). 

The synchronisation signal at the input port shall have frequency accuracy better than the one of the Node B. 

The relative phase difference of the synchronisation signals at the input port of any Node B in the synchronised area 
shall not exceed 2.5 )is. 
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Figure 7: Synchronisation signal with 256 frames markers (Release 99) 




Figure 7a: Synchronisation signal with 256 and 4096 frames markers (Release 4) 

Synchronisation by a GPS receiver 

The signal transmitted by a Global Positioning System (GPS) satellite indicates the GPS time that provides an absolute 
time reference. This makes the GPS receiver suitable for Inter Node B Node Synchronisation. 

Inter Node B Node Synchronisation is achieved by relating the synchronisation signal (at the input synchronisation 
port) to the GPS signal. Since the period of this signal is 2.56 s, this implies that every 6400 frames the start of a 256 
frame period coincides with an integer GPS second, i.e. a multiframe shall start when GPS time mod 64 = 0. 
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In general, at each start of a GPS second indicating the GPS time in seconds, the associated full SFN (the 12 bits value) 
can be derived as: SFN = (GPS time * 100) mod 4096. If the synchronisation port signal shall be derived from GPS, the 
special pulses for the 256 frames period and the 4096 frames period shall be present in the synch port signal when SFN 
mod 256 = or SFN mod 4096 = 0, respectively, where the SFN in these equations is linked to the GPS time by the 
said equation. 

Backward compatibility to Release 99 

The Release 4 synchronisation port definition is backward compatible with the Release 99 synchronisation port in the 
following sense: It is possible to feed a Release 99 Node B with the Release 4 synchronisation port signal. This results 
from the fact that the Release 4 synchronisation port pulses defined for SFN mod 256 = and those defined for SFN 
mod 4096 = both meet the pulse width tolerance defined for SFN mod 256 = in Release 99. So the Release 99 Node 
B will recognise these two classes of Release 4 pulses as valid Release 99 pulses for definition of the 256 frames 
multiframe start. The Release 99 Node B will, however, ignore the differences between the 256 frames period pulse and 
the 4096 frames period pulse: The result is the 256 frames multiframe synchronisation as specified for Release 99. 

The opposite scenario, however, i.e. connecting a Release 99 synchronisation port signal (without the 4096 frames 
marker) to a Release 4 Node B, shall be excluded. This would cause confusion for the "synchronisation via radio 
interface" procedure. The TDD cells in Release 4 shall be either "reference" cells where the SFN is fully synchronised 
to an external reference, or they shall be "non-reference" without any external, local frame clock reference. 

6.1 .2.2 TDD Inter Node B Node Synchronisation procedure 

The Node B synchronisation procedure is an optional procedure based on transmissions of cell synchronisation bursts in 
predetermined PRACH time slots according to an RNC schedule. Such soundings between neighbouring cells facilitate 
timing offset measurements by the cells. The measured timing offset values are reported to the RNC for processing. The 
RNC generates cell timing updates that are transmitted to the Node B and cells for implementation. 

The synchronisation procedure has four phases to bring a network into a synchronised operation, the preliminary phase, 
the frequency acquisition phase, the initial phase and the steady-state phase. The procedure for late entrant cells is 
slightly different and is described separately. 

For synchronisation via the air interface it has to be considered that as long as a cell is not synchronised the cell may 
interfere the neighbouring cells. This applies especially in case of late entrant cells where first the new cell has to be 
setup before the synchronisation procedure starts. By this Cell Setup procedure the SCH is already transmitting. The 
RNC shall therefore disable the downlink time slots on Cell Setup procedure by means of the Time slot Status IE. When 
the cell synchronisation has been performed the downlink time slots shall be enabled by means of the Cell 
Reconfiguration procedure. 

6.1.2.2.1 Preliminary Phase 

1) There should be at least one cell in each RNC area (i.e. in the RNS) which is synchronised by an external 
reference (e.g. GPS receiver). The cells with reference timing shall initialise their SFN counter so that the frame 
with SFN=0 starts on January 6, 1980 at 00:00:00 GMT. 

2) The RNC has to be informed at which of the cells the external reference clock is connected. Therefore, a 
'Reference Clock availability' indicator is added within the RESOURCE STATUS INDICATION message that 
is sent from the Node B to the RNC when a Local Cell becomes existing at the Node B. 

3) At Cell Setup a 'Reference SFN offset' may be given to the cells where the reference clock is connected in order 
to separate the synchronisation bursts from different RNC areas. 

4) The RNC has to retrieve the reference time from the cells with the reference clock. For the reference time 
retrieval the DL Transport Channels Synchronisation procedure or the Node Synchronisation procedure on the 
PCH frame protocol (see [4]) shall be used. The Node B shall consider the SFN derived from the synchronisation 
port and the Reference SFN offset given by the RNC. 

5) Now the RNC proceeds by updating the timing of all the remaining cells in the RNS, instructing them to adjust 
their clocks. Therefore, first the DL Transport Channels Synchronisation procedure on the PCH frame protocol 
shall be performed in order to determine the deviation from the reference SFN. The RNC then sends a CELL 
SYNCHRONISATION ADJUSTMENT REQUEST message to all the cells for SFN update, apart from the 
one(s) containing the reference clock. The cells shall adjust their SFN and frame timing accordingly. 
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6. 1.2. 2.1 A Frequency Acquisition Phase 

The frequency acquisition phase is used to bring cells of an RNS area to within frequency limits prior to initial 
synchronisation. No traffic is supported during this phase. 

1) The cell(s) identified as reference cell, i.e. external reference clock is connected to, shall transmit continuously 
cell synchronisation bursts in every time slot where possible according to the information's given in the CELL 
SYNCHRONISATION INITIATION REQUEST message. 

2) All other cells are considered as unlocked (i.e. not in frequency lock) shall listen for transmission from other 
cells and perform frequency locking to any transmission received. For setting the parameters within the Node B 
to listen for transmission from other cells, the CELL SYNCHRONISATION INITIATION REQUEST message 
is used. 

3) A cell shall signal completion of frequency acquisition to the RNC, as soon as it has locked its frequency to the 
received signal, fulfilling the Frequency Stability requirement set in [17]. 

4) If the cell(s) have received transmission request on instructing the frequency acquisition and the cell(s) have 
performed frequency locking, the cell(s) shall begin transmitting the specified code for frequency locking of 
other cells. 

5) When the RNC has received completion of frequency acquisition signals from all cells the frequency acquisition 
phase is completed. 

6.1. 2.2. IB Initial Phase 

The procedure for initial synchronisation is used to bring cells of an RNS area into synchronisation at network start up. 
No traffic is supported during this phase. 

1) For the synchronisation procedure it is useful to know which cells can "hear" each other. Therefore, all cells are 
instructed to transmit their cell synchronisation bursts in turn one after the other. The same cell synchronisation 
burst code and code offset is used by all cells. 

2) Each cell shall listen for transmissions from other cells. Each cell shall report the timing and received SIR of 
successfully detected cell sync bursts to the RNC. 

3) Upon reception of a CELL SYNCHRONISATION ADJUSTMENT message the cell shall adjust its timing 
accordingly. The timing adjustment shall be completed before the CELL SYNCHRONISATION 
ADJUSTMENT RESPONSE message is sent. It shall be implemented by adjusting the timing and/or tuning the 
clock frequency. 

4) Steps 1 to 3 are repeated as often as necessary in order to reach the minimum synchronisation accuracy defined 
in [16]. This serves the purpose to bring the network into tight synchronisation. 

The SIR value within the cell sync burst reports is used by the RNC to define the schedule for the steady-state 
phase. I.e. to define when which cells transmit a cell synchronisation burst and when which cell synchronisation 
bursts shall be received. Cells which are sufficiently separated can be allowed to send the same cell 
synchronisation burst at the same time. Cells which are not sufficiently separated have to use different cell 
synchronisation codes and code offsets for distinctions. 

6.1.2.2.2 Steady-State Phase 

The steady-state phase allows cells to reach and/or maintain the required synchronisation accuracy. With the start of the 
steady-state phase traffic is supported in a cell. The steady-state phase starts with the Cell Synchronisation 
Reconfiguration procedure (see [3]) which defines the synchronisation schedule. I.e. each cell gets the information 
when to transmit a cell synchronisation burst and when the individual cell synchronisation bursts from the neighbouring 
cells shall be measured. 

For definition of the SEN when the cell shall transmit or receive cell synchronisation bursts, the SEN period is divided 
into cycles that have the same schedule. Within each cycle the Frame numbers for the cell synchronisation bursts are 
calculated by the number of repetitions per cycle and by an offset. Code and code offset are used to identify the 
individual cell synchronisation bursts. 

1) The cell shall transmit a cell synchronisation burst and measure cell synchronisation bursts from neighbouring 
cells according to the information's given in the CELL SYNCHRONISATION RECONFIGURATION 
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REQUEST message. Reception times for all relevant codes and code offsets shall be reported to the RNC with 
the CELL SYNCHRONISATION REPORT message. 

2) Upon determination of an error in timing, the RNC adjusts the cell timing by means of the CELL 
SYNCHRONISATION ADJUSTMENT message. The timing adjustment shall be started at the beginning of the 
frame with the SEN given in the command. It shall be completed by the next cell synchronisation slot. Timing 
adjustments shall be implemented via gradual steps at the beginning of a frame. The whole adjustment shall be 
implemented with maximum stepsize of one sample per frame. 

3) Step 1 and 2 continue indefinitely 

6.1.2.2.3 Late-Entrant Cells 

The scheme for introducing new cells into a synchronised RNS is as follows: 

1) Late entrant cells (new cells being added without reference clock ) or cells recovering from unavailability shall 
first be roughly synchronised. Therefore, first the DL Transport Channels Synchronisation procedure on the PCH 
frame protocol shall be performed in order to determine the deviation from the reference SEN. The RNC then 
sends a CELL SYNCHRONISATION ADJUSTMENT message to the late-entrant cells for SEN update. 

2) Erequency acquisition of the late entrant cell is started by instructing the late entrant cell first to listen to the 
regular schedule of cell sync bursts of the surrounding cells. The transmission schedule of the surrounding cells 
shall be signalled to the late entrant cell within the CELL SYNCHRONISATION INITIATION REQUEST 
message. Frequency locking is reported using the CELL SYNCHRONISATION REPORT message. 

3) In addition or instead of a regular schedule a single common cell synchronisation burst is transmitted in parallel 
by cells which are synchronised in the system and which are preferably the ones surrounding the late-entrant 
cell. The single cell synchronisation burst is initiated by means of the CELL SYNCHRONISATION 
INITIATION REQUEST message to the surrounding cells. 

4) The late entrant cell shall correlate against the cell synchronisation burst according to the measurement 
information within the CELL SYNCHRONISATION INITIATION REQUEST message. The reception window 
shall be +1- 3 frames around the SEN frame given in the measurement information. The late entrant cell shall 
take the earliest reception as the timing of the system and adjusts its own timing and SEN number accordingly. 

5) Thereafter, the late entrant cell shall start regular measurements after the reception of a CELL 
SYNCHRONISATION RECONEIGURATION REQUEST message and it shall report the timing of the 
measured cell synchronisation bursts to the RNC. In turn, the late entrant cell receives its own schedules for 
synchronisation transmissions and receptions and enters the steady-state phase. 



Transport Channel Synchronisation 



7.1 General 

The Transport Channel (or L2) synchronisation provides a L2 common frame numbering between UTRAN and UE 
(frame synchronisation between the L2 entities). This frame number is the Connection Erame Number (CEN) and it is 
associated at L2 to every TBS and passed to LI: the same CEN is received on the peer side associated with the same 
TBS. 

The CEN is not transmitted in the air interface for each TBS, but is mapped by LI to the SEN of the first radio frame 
used for the transmission of the TBS (the SEN is broadcast at LI in the BCH). The mapping is performed via the Erame 
Offset parameters (see Eigure 8). 



£75/ 



3GPP TS 25.402 version 4.5.0 Release 4 



22 



ETSI TS 125 402 V4.5.0 (2002-06) 



RNC 



NodeB 



UEDL 




150 

_L_ 



151 

_L_ 



153 

_L_ 



CFN 



IXDataFramB 

[CFN =150] 



CFN 



IXj Radio Etame 



SFN 



iQEfset 



UL Radio Btame 



150 \ 151 152 

UL is delayed To oompaied with DL 



153 CFN 



Frame arrons represent first chip or first bit infizuries, 771=10 ins, [FDD - Oiip Offset = 0] 



Figure 8: Transport Channel Synchronisation 

This transport channel synchronisation mechanism is vaHd for all downlink transport channels. 

In case of soft handover (i.e. only for DCHs), the Frame Offsets of the different radio links are selected in order to have 
a timed transmission of the diversity branches on the air interface (see Figure 9). 
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Figure 9: [FDD - Transport Channel Synchronisation during soft handover] 
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7.2 Timing adjustment and Time of Arrival monitoring on lub/lur 
interfaces 

A receiving window is configured in Node B at Transport bearer Setup and Reconfiguration for DL frames (TOAWS 
and TOAWE). The purpose is to make it possible to supervise whether data frames are received in the window or not. 
When a frame is received outside that window, a response is sent to RNC by means of a Timing Adjustment Control 
frame containing the Time of Arrival information (TOA)(see Figure 10 and Figure 11). This allow the LI to indicate to 
L2 (through the LI -MAC primitive carried by the Timing Adjustment Control frame) the necessity to adjust the timing 
of the DL transmission, in order to control and minimise the transmission delay and the buffering time for the 
transmission on the air interface (i.e. to ensure that the TBS does not arrive too much in advance respect to the 
transmission time). 
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Figure 10: Illustration of TOAWS, TOAWE, LTOA and TOA 

The window could be defined to have a margin before LTOA (TOAWE >0). This is to indicate to RNC that data frames 
are a bit late but they are still processed by Node B. In this case, data frames are received after TOAWE but before 
LTOA. 

Using this window definition and supervising method, it is possible to determine the correct timing for sending data 
frames from the RNC over lur/ lub. 

The window size and position is chosen with respect to expected data frame delay variation and different 
macro-diversity leg delays. 



ETSI 



3GPP TS 25.402 version 4.5.0 Release 4 



24 



ETSI TS 125 402 V4.5.0 (2002-06) 



SRNC 



NodeB 




CFN 



CFN 



L Receivim Window , 1 



Figure 1 1 : Timing Adjustment Procedure 

In order to monitor the TOA when no DL data frames are sent, a synchronisation procedure is defined in the lub/Iur 
frame protocols ([4], [5]). This procedure makes use of UL and DL Synchronisation Control frames (see Figure 12 and 
Figure 13). The SRNC sends DL Synchronisation Control frame containing the CFN in which the control frame should 
be received by the Node B. When the Node B receives the DL Synchronisation Control frame, it always replies with an 
UL Synchronisation Control frame containing the TOA, even if the DL Synchronisation Control frame is received 
within the receiving window as in Figure 12. 
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Figure 12: TOA monitoring through Frame Protocol Synchronisation Procedure (TOA > 0) 
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Figure 13: TOA monitoring through Frame Protocol Synchronisation Procedure (TOA < 0) 

In case of macrodiversity with recombining in the DRNC, the DL Synchronisation control frame is dupHcated in the 
DRNC on the different links, while the UL Synchronisation control frames received from all the Node B's are 
forwarded transparently to the SRNC (see Figure 14). 
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Figure 14: [FDD - TOA monitoring through FP Synchronisation Procedure during soft handover with 

selection/recombining in the DRNC] 

Once the SRNC receives the two UL Synchronisation control frames containing TOAl and TOA2, it may consider 
either TOAl or TOA2 to advance or delay DL transmission (see Table 1). 

Table 1 



Relation between TOAl and T0A2 


TAO considered and action performed by tlie SRNC 


TOAl < T0A2 < 


TOAl may be considered to advance DL transmission 


T0A2 < T0A1 < 


T0A2 may be considered to advance DL transmission 


TOM < 0, T0A2 > 


TOAl may be considered to advance DL transmission 


T0A2 < 0, T0A1 > 


T0A2 may be considered to advance DL transmission 


TOAl > T0A2 > 


T0A2 may be considered to delay DL transmission 


T0A2 > T0A1 > 


TOAl may be considered to delay DL transmission 
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8 Radio Interface Synchronisation 

8.1 General 

This subclause describes the Radio Interface Synchronisation for FDD and TDD. 

8.2 FDD Radio Interface Synchronisation 
8.2.1 General 

FDD Radio Interface Synchronisation assures that UE gets the correct frames when received from several cells. The UE 
measures the Timing difference between its DPCH and SFN in the target cell when doing handover and reports it to 
SRNC. SRNC sends this Time difference value in two parameters Frame Offset and Chip Offset over lub to Node B. 
Node B rounds this value to the closest 256 chip boundary in order to get DL orthogonality (regardless of used 
spreading factor). The rounded value is used in Node B for the DL DPCH. 

DOFFpoD is selected by the SRNC considering the interleaving period (e.g. 10, 20, 40 or 80 ms) when entering in 
dedicated state from common channel state. 

Services are scheduled by using DOFFfdd in order to average out the lub traffic load and the Node B processing load. 
DOFFpDD (FDD Default DPCH Offset value) is only used when setting up the first RL in order to initialise Frame 
Offset and Chip Offset and to tell UE when frames are expected. 

UE uses the UL DPCH as it is a more defined time instant compared with DL DPCH. 

The handover reference is the time instant Tuetx -To, which is called DL DPCH^om in the timing diagram. 

Tceii is used to skew cells in the same Node B in order to not get colliding SCH bursts, one SCH burst is 1/10 of a slot 
time. 

The timing diagram in Figure 15 shows an example with two cells connected to one UE where handover is done from 
source cell (Cell 1) to target cell (Cell 2). 
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Figure 15: FDD Radio Interface Synchronisation timing diagram 

SFN, is found in Cell 1 at Node B, and SFN2 at Cell 2 and Node Bj. SEN, is sent T_celli after the Node B, reference 
BFNi. CFN is the frame numbering that is related to each DL and UL Dedicated Physical Channel (DPCH). UL DPCH 
is sent from UE to both Cells (both Node B's in this example). UL DPCH2 at Node B2 is shown to indicate the 
difference to the DL DPCH2 at Node B2. 

The new RL (DL DPCH2) which is setup at the HO will face some deviation from nominal position due to the rounding 
of Frame Offset and Chip Offset to 256 chip boundary in Node B. Time dispersion and UE movements are examples of 
other factors affecting this phase deviation. 

The nominal DL DPCH timing at UE is To before the Tuetx time instant, which could be expressed: 

DLDPCH„o„ = TuETx-To (8.1) 

In UE dedicated state, OFF and Tm are measured at UE according to the following equation: 

OFF + Tm = (SFN„,ge,-DL DPCH„oJ mod 256 frames [chips] (8.2) 

NOTE: OFF has the unit Frames and Tm the unit Chips. 
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EXAMPLE 1: Assume that OFF + T^ equals "3.3300" frames (as given as an example in 

Figure 15). Then OFF = 3 and T^, = "0.33" which corresponds to T^, = 12672 chips. 

In other words (referring to the timing diagram in Figure 15): 

How to determine T^, at UE: Select a time instant 1) where frame N starts at DL SFN2 e.g. frame number 3, the 
time from that time instant to the next frame border of DL DPCHnom 2) equals T^, 
(if these are in phase with each other, T^, is zero). 

How to determine OFF: The difference between the frame number selected for time instant 1) and the frame 

number starting at instant 2) mod 256 frames equals OFF. 

EXAMPLE 2: (3 -0) mod 256 = 3, another example is (1 -254) mod 256 = 3. 

8.2.2 Neighbour cell list timing information 

A cell can optionally broadcast a neighbouring cell list that indicates timing information for neighbouring cells. The list 
contains the inter cell timing difference to neighbour cells with associated estimated uncertainty. The inter cell timing 
uncertainty depends on what timing difference estimating means that are used in the system (No means at all, Node 
synchronisation measurements, UE inter-cell measurements. Cells belonging to the same Node B or even GPS). The 
purpose with the neighbouring cell list timing information is to enable shorter cell search time for UE, to save UE 
battery and to potentially lower BCH Tx power for cells in a synchronised cluster. 

8.3 TDD Radio Interface Synchronisation 
8.3.1 General 

The TDD Radio Interface Synchronisation relates to the following two aspects: 

Intercell Synchronisation; 

Timing Advance for 3.84Mcps TDD and Uplink Synchronisation for 1.28Mcps TDD. 
In TDD mode Intercell Synchronisation may be achieved by means of: 

Inter Node B Node Synchronisation that allows to achieve a common timing reference among Node B's. 

The Radio Interface Synchronisation between UE and UTRAN is achieved by means of the Timing Advance 
mechanism. 



8.3.2 Intercell Synchronisation 



Intercell Synchronisation ensures that the frame boundaries are positioned at the same time instant in adjacent cells (see 
Figure 16). 

This requirement is necessary to minimise the interference between UEs in neighbouring cell. 

In addition it automatically ensures that the slots of different cells are synchronised, i.e. they do not overlap at the UE. 
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Figure 16: Intercell Synchronisation 
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Furthermore, Intercell Synchronisation assures the synchronisation of the last 8 bits of the SFN, that is required if frame 
wise hopping mechanisms among cells are used. It also can be used to keep more efficient and faster all procedures 
involving a switch from one cell to another, such as searching for new cells, locking to new cells or handover. 

8.3.3 Multi Frame Synchronisation 

Void. 

8.3.4 Timing Advance for 3.84Mcps TDD 

Timing Advance is used in uplink to align the uplink radio signals from the UE to the UTRAN both in case of uplink 
Dedicated Physical Channels (DPCH) and of Physical Uplink Shared Channels (PUSCH). 

The handling of timing advance can be divided in four main categories: measurement, initial assignment, updates 
during operation, and setting on handover. For each category, a number of different cases can be distinguished. 

1 . Measurement of the timing deviation on the physical channels: 

On PRACH transmissions; 
On DPCH transmissions; 
On PUSCH transmissions. 

2. Assignment of correct timing advance value when establishing new channels: 

- At transition to CELL_DCH state; 

- When establishing an USCH in CELL_FACH state. 

3. Update of timing advance value for channels in operation: 

- UE in CELL_DCH state; 

- UE with USCH in CELL_FACH state. 

4. Setting of timing advance value for target cell at handover: 

Handover from TDD to TDD with synchronised cells; 
Handover from TDD to TDD with unsynchronised cells; 
Handover from FDD to TDD; 
Handover from other systems to TDD. 

8.3.4.1 Measurement of the timing deviation on the physical channels 

Timing deviation measurements are always performed in the physical layer in Node B. These measurements have to be 
reported to the higher layers, where timing advance values are calculated and signalled to the UE. For this reporting, a 
number of different ways are foreseen, depending on the used physical channels. 

PRACH: The Node B physical layer measures the timing deviation of the received PRACH signal (RX 

Timing Deviation) and passes this together with the transport block to the CRNC (by means of the 
lub RACH Frame Protocol). In case the RACH carries a DDCH or DTCH, the measured timing 
deviation may be passed from DRNC to the SRNC over lur interface (by means of the lur RACH 
Frame Protocol). 

NOTE: PRACH transmissions themselves are transmitted with a large guard period so they do not require timing 
advance. 

PUSCH: The Node B physical layer measures the timing deviation of the received PUSCH signal (RX 

Timing Deviation) and passes this together with the transport block to the CRNC (by means of the 
lub USCH Frame Protocol). 
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DPCH: The Node B physical layer measures the timing deviation of the received DPCH signal (RX 

Timing Deviation) and passes this value, if the conditions for reporting the measurement are met, 
to the SRNC (by means of the lub & lur DCH Frame Protocols). 

8.3.4.2 Assignment of correct timing advance value when establishing new channels 

8.3.4.2.1 Transition to CELL_DCH State 

The transition to CELL_DCH state from CELL_FACH state or Idle Mode operates in the following manner: 

The SRNC checks whether an up to date timing deviation measurement is available. Such a measurement can be 
available from a recent RACH access (e.g. from initial access) or from a recent USCH transmission. If no up to 
date timing deviation measurement is available, e.g. because of lack of uplink transmissions, or during USCH 
over lur, the SRNC is not informed about RX Timing Deviations, and has to trigger an uplink transmission from 
the UE before it can assign a DCH (for example, a RRC procedure requiring a response from the UE). The 
SRNC calculates the required timing advance value and saves it in the UE context in the SRNC for later use in 
dedicated or shared channel activation. 

The SRNC attaches the timing advance value to the channel allocation message that it signals to the UE via 
EACH (RRC message CONNECTION SETUP or RRC message RADIO BEARER SETUP). 

When the UE receives the channel allocation message it configures its physical layer with the given absolute 
timing advance value. When a timing advance command is signalled to the UE, the CFN that the new timing 
advance is to be applied is always signalled. 

8.3.4.2.2 When establishing an USCH in CELL_FACH state 

For uplink traffic using the USCH, short time allocations are sent to the UE regularly. Therefore establishing an USCH 
in CELL_FACH state is very similar to handling of timing advance updates during USCH operation. The UTRAN shall 
use a recent timing deviation measurement. Such a measurement shall be available from a recent USCH burst or a 
recent RACH access (e.g. from the RRC message PUSCH CAPACITY REQUEST). 

8.3.4.3 Update of timing advance value for channels in operation 
8.3.4.3.1 UE in CELL_DCH state 

An UE that is operating a dedicated channel (CELL_DCH state), has to update the timing advance from time to time to 
keep the received signal at the Node B within the required time window. Under reasonable assumptions the worst case 
update frequency is in the order of 8 seconds. 

The timing advance update procedure operates in the following manner: 

1 . The SRNC determines whether a new timing advance value has to be transmitted to the UE taking into account 
the timing deviation measurements. The new timing advance value is calculated taking into account the UE's 
current timing advance value. 

2. The new timing advance value and the CFN in which it is to take effect are signalled to the UE via RRC 
signalling on EACH or DCH (PHYSICAL CHANNEL RECONFIGURATION, TRANSPORT CHANNEL 
RECONFIGURATION, RADIO BEARER RECONFIGURATION or UPLINK PHYSICAL CHANNEL 
CONTROL are examples of possible messages on the DCCH). 

3. The SRNC shall also send the updated timing advance value and the CFN in which it is to take effect to the 
Node B, using a user plan control message. The Node B may adjust its physical layer to take the change in 
uplink transmission into account. 

4. When the UE receives a new timing advance value, it shall configure its physical layer so that the updated timing 
advance value takes effect on the given CFN specified within the RRC message. The timing advance value shall 
be applied to all DPCHs and, if present, to all PUSCHs. 
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There is no need for the UE to acknowledge the timing advance update: the Node B continually measures and reports 
the UE timing deviation and the UE reports the received timing advance value as part of its measurement reporting. The 
SRNC is thus able to detect if a timing advance update has not been received and needs to be resent. 

8.3.4.3.2 UE with USCH Traffic in CELL_FACH state 

If the UE uses an USCH in CELL_FACH state (no DCH), the timing advance update procedure operates in the 
following manner: 

1 . The CRNC determines whether a new timing advance value has to be transmitted to the UE taking into account 
when the last timing advance update was signalled. Two cases are possible: 

If the data transfer is uplink after a longer idle period then the UE has to transmit a capacity request on the 
RACH. The CRNC is therefore informed of any timing deviation on this RACH. 

If a new allocation follows an USCH transmission, the timing deviation is already known to the CRNC from 
measurements of the last uplink transmission. 

2. If a Timing Advance update is needed, the CRNC includes a new timing advance value and the CFN in which it 
will take effect in the next USCH allocation message to the UE (PHYSICAL SHARED CHANNEL 
ALLOCATION). 

3. The CRNC shall also send a user plane control message indicating the CFN and the updated timing advance 
value to the Node B so the Node B can adjust its physical layer averaging to take the change in uplink 
transmission into account. 

4. When the UE receives a new timing advance value, the UE shall configure its physical layer, so that the updated 
timing advance value takes effect on the given CFN specified within the PHYSICAL SHARED CHANNEL 
ALLOCATION message. The timing advance value shall be applied to all present PUSCHs. 

8.3.4.4 Setting of timing advance value for target cell at handover 

8.3.4.4.1 General 

Since the uplink radio signals need to be adjusted only because of large enough distances between the UE and the cell 
transmission, certain cells will have a small enough radius that timing advance needs to not be used. In those cells the 
timing advance value in the UE is set to zero and UE autonomous adjustment of timing advance upon handover is 
disabled in the handover messages to the UE. 

In these cells, where TA is not applied, the "RX Timing Deviation" measurement can be omitted if no other procedure 
(e.g. LCS) requires it. 

8.3.4.4.2 Handover from TDD to TDD with synchronised cells 

When two TDD cells are involved in handover and the two cells are sufficiently synchronised, a UE is able to measure 
the time offset between P-CCPCH reception of the two cells and, consequently, is able to autonomously correct its 
timing on handover without UTRAN assistance. However to improve the accuracy for the UE calculated timing 
advance, the SRNC can include an updated timing advance based on the timing deviation measured by the old cell in 
the messages triggering the handover in the UE. Note that this update shall apply in the old cell at the specified CFN if 
handover is performed on a later CFN or if the handover fails and falls back to the old cell. The UE shall use this new 
value as the basis for the UE autonomous update. 

After a successful handover, a response message is transmitted in the new cell. In this message, if the UE autonomously 
updated its timing advance it shall report the calculated timing advance value, which it is using for access to the new 
cell. By this way, the SRNC is informed as fast as possible about the absolute timing advance value in the UE, and it 
can correct the timing advance immediately or in the future based on this value, if necessary. 

8.3.4.4.3 Handover from FDD to TDD, Handover from other systems to TDD, or Handover 
from TDD to TDD with unsynchronised cells 

In these cases, since synchronisation between the handover cells is not possible, the new TDD cell must use a burst type 
with a large enough transmission window to allow the immediate transmission of data without the need of timing 
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advance adjustment in the new cell, since timing adjustment can only be performed in these cells after the first uplink 
transmission. 

8.3.5 UL Synchronisation for 1 .28Mcps TDD 

This section describes the details of the UL synchronisation including the establishment of UL synchronisation and 
maintenance of the UL synchronisation. 

8.3.5.1 The establishment of uplink synchronisation 

8.3.5.1 .1 Preparation of uplink synchronisation by downlink synchronisation 

When a UE is powered on, it first needs to establish the downlink synchronisation with the cell. Only after the UE can 
establish and maintain the downlink synchronisation, it can start the uplink synchronisation procedure. 

8.3.5.1 .2 Establishment of uplink synchronisation 

Although the UE can receive the downlink synchronisation signal from the Node B, the distance to Node B is still 
uncertain which would lead to unsynchronised uplink transmission. Therefore, the first transmission in uplink direction 
is performed in Uplink Pilot Channel (UpPCH), to avoid interference in traffic time-slots. 

The timing used for the S YNC_UL burst are set e.g. according to the received power level of DwPCH and/or 
P-CCPCH. 

At the detection of the SYNC_UL sequence in the searching window, the Node B will evaluate the received power 
levels and timing, and reply by sending the adjustment information to UE to modify its timing and power level for next 
transmission and for establishment of the uplink synchronisation procedure. Within the next 4 sub-frames, the Node B 
will send the adjustment information to the UE (in a single subframe message in the FPACH). The uplink 
synchronisation procedure, normally used for a random access to the system, can also be used for the re-establishment 
of the uplink synchronisation when uplink is out of synchronisation. 

8.3.5.2. Maintenance of uplink synchronisation 

For the maintenance of the uplink synchronisation, the midamble field of each uplink burst can be used. 

In each uplink time slot the midamble in each UE is different. The Node B can estimate the power level and timing shift 
by measuring the midamble field of each UE in the same time slot. Then, in the next available downlink time slot, the 
Node B will signal the Synchronisation Shift (SS) and the Power Control (PC) commands to enable the UE to properly 
adjust respectively its Tx timing and Tx power level. 

These procedures guarantee the reliability of the uplink synchronisation. The uplink synchronisation can be checked 
once per 1 .28Mcps TDD sub-frame. The step size in uplink synchronisation is configurable and re-configurable and can 
be adapted from 1/8 chip to 1 chip duration. The following updates for UL synchronisation are possible: 1 step up; 
1 step down; no update. 

For 3.84Mcps TDD option, uplink synchronisation is mentioned in 4.3 of [16]. But the implementation method is a little 
different with the 1 .28Mcps TDD option. For 1 .28Mcps TDD option, the establishment of the UL synchronisation is 
done by using the UpPCH and the FPACH. 

UE will select one of the set of S YNC_UL codes which can be used in the cell to establish uplink synchronisation in the 
access procedure. The benefit of this method is when the UE wants to do random access, the PRACH will have 
minimum interference to other traffic channel. Vice versa, it will also reduce the interference from traffic channels to 
PRACH. 
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Usage of Synchronisation Counters and Parameters 
to support Transport Channel and Radio Interface 
Synchronisation 



9.1 



General 



This subclause describes how the different synchronisation parameters and counters are computed and used in order to 
obtain Transport Channel (L2) and Radio Interface (LI) Synchronisation. 

The parameters that need to be determined by the UE are CFN, OFF [FDD - and Tm] . 

The parameter that need to be determined by the UTRAN are [FDD - DOFFfdd], [TDD - DOFFtdd], Frame Offset and 
[FDD -Chip Offset]. 

Figure 17 summarises how these parameters are computed. A detailed description of the actions in each state is given in 
the sections 9.2 - 9.4, while some examples of corrections applied to synchronisation counters during UE state 
transitions are shown in section 9.5. 
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Figure 17: Calculations performed by UE and UTRAN 

Figure 18 describes what offset parameters are signalled and used in the different nodes at Initial RL setup and at 
Handover (HO) in FDD. The rounding to closest 256 chip boundary is done in Node B. The rounded Frame Offset and 
Chip Offset control the DL DPCH air-interface timing. The 256 chip boundary is to maintain DL orthogonality in the 
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cell (the rounding to the closest 256 chip boundary is done in Node B to facilitate the initial UL chip synchronisation 
process in Node B). 
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Figure18: [FDD - Usage of Offset values at initial RL and at HO] 

Figure 19 describes what offset parameters are signalled and used in the different nodes at Initial RL setup and at 
Handover (HO) in TDD. 

Note that in some cases the parameter OFF,afget cannot be measured by the UE before handover (e.g. in case of inter 
frequency handover or inter-mode handover). In these cases a value as defined in [FDD - 13] [TDD - 14] shall be 
reported by the UE. 
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Figure 19: [TDD- Usage of Offset values at initial RL and at HO] 

9.2 Calculations performed in the UTRAN 

9.2.1 UE in CELL_FACH/PCH state 

In CELL_FACH/PCH state the Frame Offset is set to (for all common and shared channels). 

9.2.2 UE changes from CELL_FACH/PCH state to CELL_DCH state: 1 RL 

[FDD - Based on the received parameters from the UE and the DOFFfdd value generated in the SRNC, the SRNC 
calculates the Frame Offset and the Chip Offset from formula (9.1): 

Frame Offset*38400 +Chip Offset = DOFFfdd*512 (9.1) 

Frame Offset and Chip Offset are then signalled to the Node B controlling the serving cell.] 

[TDD - Based on the DOFFtdd value generated in the SRNC, the SRNC calculates the Frame Offset = DOFFtdd- 

Frame Offset is then signalled to the Node B controlling the serving cell.] 

[TDD - Note that for all common and shared channels Frame Offset is set to even during CELL_DCH state.] 

9.2.3 [FDD - UE changes from CELL_FACH/PCH state to CELL_DCH 
state: several RL's] 

Based on the received parameters from the UE for each celli^ (OFF^and TmiJ and the DOFFfdd value generated in the 
SRNC, the SRNC calculates the Frame Offset,, and the Chip Offset,,. The Frame Offsets and the Chip Offset^ are 
calculated from formula (9.2): 



Frame Offsetk*38400 + Chip Offsetk = DOFFfdd*512 + OFFk*38400 + Tm^ 



(9.2) 



NOTE: Formula (9.2) is covering formula (9.1) since in the case described in section 9.2.2, OFF^ and Tmj, are 
both equal to zero. 

Each Frame Offset^ and Chip Offset^ are then signalled to the Node B controlling the cell^. 
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9.2.4 UE in CELL_DCH state: addition of a new RL or Inandover to a new 
cell 

[FDD - Based on the received parameters from the UE or already known by the UTRAN (OFFt^rgeb Tmtarget)^ the SRNC 
calculates the Frame Offsetjarget and the Chip Offsettarget with formula (9.3): 

Frame Offsett,,get*38400 + Chip Offset t,,get= OFFt,,get*38400 + Tm„,ge, (9.3) 

During hard handover in case the parameter OFFtarget cannot be measured by the UE and it is not already known by the 
UTRAN, than the SRNC calculates the Frame Offsettaige, and the Chip Offset,arget with formula (9.1). 

Frame Offsettarget and Chip Offsettarget are then signalled to the Node B controlling the target cell.] 

[TDD - Based on the parameter OFFtarget received from the UE or already known by the UTRAN, the SRNC calculates 
the Frame Offset,arget = OFFtarget- 

In case the parameter OFFtarget cannot be measured by the UE and it is not already known by the UTRAN, than the 
SRNC calculates the Frame Offsettarget = DOFFtdd- 

It is signalled to the Node B controlling the target cell.] 

9.2.5 Handover from other RAN to UMTS 

[FDD - Based on the definitions for OFF and Tm formula (9.1) can also be used when the UE enters the UTRAN from 
another CN and establishes one dedicated RL. The same is true for formula (9.2) when establishing one or more 
dedicated RL's.] 

[TDD - When the UE enters the UTRAN from another CN and establishes one dedicated RL, OFF is 0. ] 

9.3 Calculations performed in the UE 
9.3.A UE in CELL_FACH/PCH state 

In CELL_FACH/PCH state the CFN is initialised with the values CFN = SEN for PCH and CFN = SEN mod 256 for all 
other common and shared channels. The CFN for all common and shared channels in the CRNC is increased (mod 256) 
by 1 every frame, except PCH, which CFN has the same range of the SEN. 

9.3.1 UE changes from CELL_FACH/PCH state to CELL_DCH state: 1 RL 

[FDD - Based on the received DOFFfdd and the SEN of the cell in which the UE is source, the UE can initialise the 
CFN with the value given by formula (9.4): 

CFN = (SEN - ((DOFFfdd * 5 12) div 38400)) mod 256 (9.4) 

This formula gives the CFN of the downlink DPCH frame which starts at the same time as or which starts during the 
PCCPCH frame with the given SEN.] 

[TDD - Based on the received DOFFtdd, the UE can initialised the CFN with the value given by formula (9.5): 

CFN = (SEN- DOFFtdd) mod 256 (9.5)] 

After the initialisation, the CFN in the UE is increased (mod 256) by 1 every frame. 

[TDD - Note that for all common and shared channels CFN = SEN mod 256 even during CELL_DCH state.] 

9.3.1 A [FDD - UE changes from CELL_FACH/PCH to CELL_DCH state: 
several RL's] 

The UE reports to the SRNC the parameters OFFj^ and Tm^ for each cellj^ measured respect to the reference cellj 
determined by means of formula (9.6): 
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OFFk + Tmk= (SFNk - CFN) mod 256 (9.6) 

After having performed OFF^ and Tm^ measurements for all target cells, the UE initialises the CFN with the value 
given by formula (9.7), based on the received DOFFfdd and the SFNj of the reference cell: 

CFN = (SFNj - ((DOFFpDD * 5 12) div 38400)) mod 256 (9.7) 

This formula gives the CFN of the downlink DPCH frame which starts at the same time as or which starts during the 
PCCPCH frame with the given SFN. 

After the initialisation, the CFN in the UE is increased (mod 256) by 1 every frame. 

9.3.2 UE in CELL_DCH state: addition of a new RL or iiandover to a new 
cell 

The UE in CELL_DCH state may be requested by the UTRAN to report OFFtarget by means of System Info broadcast in 
the source cell. 

[FDD - In case the SFNtargetCan be measured, the target cell OFFtarget is calculated using formula (9.8): 

OFFt^get + Tmta,ge,= (SFN,a,ge, - CFN) mod 256 (9.8) 

otherwise a value as defined in [13] is reported. Tm^iget is always reported, except for the case of FDD-TDD handover.] 



[TDD - In case the SFNtargetCan be measured, the target cell OFFtarget is calculated using formula (9.9): 

OFFt^get = (SFN,a,ge. "CFN) mod 256 (9.9) 

otherwise a value as defined in [14] is reported.] 
Note that, regarding the CFN, two cases may occur: 

a) the value of OFFtarget is known by the UTRAN before handover execution: 

al) either because the SFNt^rgethas been measured by the UE and reported to the UTRAN by means of the 
OFFtarget before handover; 

a2) or because the UTRAN already knows the difference between serving cell SFN^ource and target cell SFNtarget 
and derives OFFtarget from OFFsource by applying the difference between SFNtarget and SFNsot,rce (this 
difference between SFNs may be known in the UTRAN from previous UE's measurement reports); 

a3) [TDD - or because cells involved in the handover are synchronised - and hence OFFtarget equals OFFsource ]■ 

b) the value of OFFtarget is not known by the UTRAN before handover execution because the SFNtarget cannot be 
measured by the UE before handover and the UTRAN does not know the difference between serving cell SFN and 
target cell SFN. 

In case a) the UTRAN shall not signal to the UE any value of [FDD- DOFFpoo] [TDD- DOFFtdd] before handover in 
the RRC message PHYSICAL CHANNEL RECONFIGURATION, and the UE shall maintain the old CFN, i.e. no 
correction to CFN is needed during handover. 

In case b) the UTRAN shall signal to the UE the new value of [FDD- DOFFfdd] [TDD- DOFFtdd] before handover by 
means of the RRC message PHYSICAL CHANNEL RECONFIGURATION. The CFN shall be re-initialised after 
handover (as soon as the UE reads the SFNtarget) according to formula [FDD- (9.4)] [TDD- (9.5)]. 

Note that in cases a2) and a3) the UTRAN may not request the UE to report OFFtarget, while in case b) the value of 
OFFtarget reported by the UE is the one defined in [FDD - 13], [TDD - 14] for this case. 

9.4 Synchronisation of L1 configuration changes 

When a synchronised LI configuration change shall be made, the SRNC commands the related Node B's to prepare for 
the change. When preparations are completed and SRNC informed, serving RNC decides appropriate change time. 
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SRNC tells the CFN for the change by a suitable RRC message. The Node B's are informed the CFN by RNSAP and 
NBAP Synchronised Radio Link Reconfiguration procedures. 

At indicated switch time UE and Node B's change the LI configuration. 

9.5 Examples of synchronisation counters during state 
transitions 

The example of Figure 20 shows the corrections applied to UTRAN synchronisation counters during multiple 
transitions from CELL_FACH/PCH state to CELL_DCH state before and after handover, without SRNS relocation. In 
this example two handover cases described in 9.3.2 are considered. 
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Figure 20: Example 1 

The example of Figure 21 shows the corrections applied to UTRAN synchronisation during multiple transitions from 
CELL_FACH/PCH state to CELL_DCH state after cell reselection, without SRNC relocation. 
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Figure 21 : Example 2 

The example of Figure 22 shows the corrections applied to UTRAN synchronisation counters during multiple 
transitions from CELL_FACH/PCH state to CELL_DCH state before and after handover and SRNS relocation (without 
UE involvement). In this example two handover cases described in 9.3.2 are considered. 
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Figure 22: Example 3 
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10 Time Alignment Handling 



The purpose of the time ahgnment procedure over lu is to minimise the buffering delay in SRNC by controlHng the DL 
transmission timing in the CN node. The time alignment procedure is controlled by SRNC and is invoked whenever the 
SRNC detects the reception of lu User Plane PDU at an inappropriate timing that leads to an unnecessary buffering 
delay. The SRNC indicates to the CN node by means of a Time Alignment control frame. The necessary amount of the 
delay or advance adjustment is indicated by expressing a number of (+/-) 500 ps steps (see Figure 23). 
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Figure 23: Time Alignment Handling 

A supervision timer T^a is started after sending the Time Alignment control frame in order to supervise the reception of 
the Time Alignment Acknowledgement control frame. 

The requested CN node adjusts the transmission timing by the amount as indicated by SRNC and sends a time 
alignment acknowledgement frame (ACK). Upon reception of a time alignment acknowledgement frame, the SRNC 
stops the supervision timer Tta- 

The procedure can be signalled at any time when transfer of user data is not suspended by another control procedure. 

If the Time Alignment control frame could not be handled by the requested CN node, a time alignment negative 
acknowledgement control frame (NACK) is sent with a corresponding cause. When the SRNC receives a NACK with 
cause "Time Alignment not supported", then the SRNC shall not send additional Time Alignment frames for that RAB 
(unless the lu User Plane conditions change for that RAB). The cause value "Requested Time Alignment not possible" 
is used to indicate that the requested time alignment was not possible at that moment. At a later moment the SRNC may 
initiate a new Time Alignment command when needed. 

If the SRNC detects that the time alignment command has not been correctly interpreted or received, i.e. NACK 
received or timer expires, and the time alignment need still persists, the SRNC should re-trigger a time alignment 
procedure. If after "k" repetitions, the error situation persists, the SRNC take appropriate local actions. 

Upon reception of a NACK, the SRNC stops the supervision timer Txa- 



In order to avoid oscillation in the time ahgnment handling over lu, it is beneficial to avoid initiating a new Time 
Alignment procedure too early after successful completion of a Time Alignment procedure. 
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